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Abstract 

This paper begins by describing the human factors design process in developing a shuttle 
orbiter aft flight deck workstation testbed. The design methodology is presented along with the 
results of the design and the problems and solutions regarding human factors design principles. 

1.0 Introduction 

1.1 Purpose of the Paper 

The purpose of this paper is to describe how to direct a design effort focused on the human 
operator. In developing an operator workstation to control various laboratory telerobots, strong 
elements of human factors engineering and ergonomics are integrated into the design process. The 
integration of human factors is performed by incorporating user feedback at key stages in the 
project life-cycle. An operator centered design approach helps insure the system users are working 
with the system designer in the design and operation of the system. Through practical experiences 
at the Goddard Space Flight Center(GSFC) Robotics Laboratory, a project plan is being 
implemented which will aid in achieving an operator centered approach. 

The described project plan represents an approach to incorporating human factors into the 
design process. Other designers of operator centered projects can follow the model described in 
this paper. Some elements in the project plan, which are directed toward telerobot workstations 
and the GSFC Robotics Lab, may not be applicable to other systems. 

1.2 Background on the Project 

One of the purposes of the Robotics Laboratory at the NASA Goddard Space Flight Center is to 
develop Flight Telerobotic Servicer(FTS) task scenarios. The task scenarios are laboratory 
versions of the tasks to be performed by FTS on Space Station Freedom(SSF), the Demonstration 
Test Flight(DTF-2) and to a lesser extent, the Development Test Flight(DTF-l). These scenarios 
are integrated, end-to-end, from the operator interface to robot worksite hardware. The scenario 
integration process is driven by various disciplines including human factors. 

The FTS robot is controlled from both the National Space Transportation System(NSTS) and 
the SSF workstations. The Robotics Laboratory at Goddard provides FTS and DTF emulation 
using a pair of force-reflective robot amis. A gantry robot is used to emulate a transport system for 
the FTS and DTF-2. Functional mock-ups are constructed for both of the NSTS and SSF 
workstations. The NSTS mock-up workstation reflects the Aft Flight Deck(AFD) area. 

1.3 Reasons for Integrating Human Factors 

The human factors discipline needs to be incorporated into the development of the AFD 
workstation because of the significant human operator role in system performance. The human 
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operator has capabilities and limitation. Furthermore there are constraints and limitations due to the 
NSTS and FTS systems. These constraints are due to the NSTS AFD and the FTS requirements 
and tasks. The AFD puts constraints on the design because of spatial limitations(2 Sq. Ft. control 
and display area), visual limitations(little or no direct viewing) and operational limitations(FTS 
operator must not interfere with other operators). The FTS mandates one person operation and 
tasks requiring dexterity from the operator. These constraints affect operator interface design 
significantly. To ensure that the system can be operated effectively and safely, an approach that 
addresses operator requirements as well as system requirements is necessary. 

2.0 Project Plan to Integrate Human Factors 

A project plan for integrating human factors into telerobot workstation design was initiated in 
the fall of 1988. The plan is now in the preliminary design phase. 

2. 1 The Design Goals 

The AFD mock-up workstation at Goddard serves several purposes. First, the operator 
workstation interfaces to a number of different robot systems. The Goddard Robotics 
Laboratory’s control system development approach is to implement a NASREM-compliant control 
system independent of the underlying hardware. The operator interface is designed to be a 
modular subsystem of the overall NASREM control architecture. The control system interfaces are 
isolated within the NASREM architecture. The workstation serves as the operator control point for 
a variety of different robotic systems in the laboratory and provides modularity and flexibility for 
future evolution. 

Another purpose of the workstation testbed is to utilize existing operator interface technology 
and apply human factors principles and guidelines in a testbed facility. The AFD workstation 
development project offers an excellent opportunity to apply many of the human factors 
engineering results already developed under previous NSTS and SSF research and development 
efforts. To make the workstation testbed as similar to flight as possible, requirements and 
constraints from both FTS and NSTS Aft Flight Deck are applied. 

Finally, the workstation testbed project is developing a human factors design methodology that 
ensures the requirements of the user are effectively met. The laboratory mock-up workstation is 
being developed at the same time and within the overall framework of the NASREM-compliant 
control system. Furthermore, the mock-up workstation requirements are driven by the constraints 
of the NSTS AFD workstation for the FTS. By emphasizing human factors, end user 
requirements are addressed throughout the development process. It is also recognized that user 
requirements and operator interface capabilities change and this change involves trade-offs based 
on hands-on evaluation by the users. Therefore, the development philosophy is to provide 
testability, adaptability and future evolution in the workstation testbed. 

2.2 The Project Plan 

A project plan is devised to effectively integrate human factors into the design process. The 
initial step of this plan is to organize a formal design team composed of engineers, computer 
systems developers, robot system operators and human factors specialists. Due to the extensive 
nature of human factors, at least one team member must be trained in human factors research. 

Also, feedback from the user community must be incorporated for good human centered 
design. In order to coordinate feedback, contacts are identified and fostered with other teams 
working on related human factors projects or research. 
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After forming the design team, objectives and deliverables are developed. The objectives for 
the team reflect typical design procedures: 

1. Task Analysis 

2. Requirements Definition 

3. Preliminary Design 

4. Detailed Design 

5. Fabrication 

6. Test and Evaluation. 

The workstation testbed project began with personnel at Goddard working without robot 
operators and human factors specialists. The team members were software designers and 
programmers with an interest in human factors. The goal was to develop a well-engineered 
telerobot workstation testbed that conforms to the basic principles of human factors design. It was 
soon determined that the task was too large and too complex for the design team. A specialist in 
human factors and ergonomics joined the team, and contacts were established with the design 
engineers, human factors experts and astronaut crew representatives engaged in FTS workstation 
development at the Johnson Space Center(JSC). 

Throughout the entire design process, reviews were conducted. These reviews were conducted 
with the intention of receiving operational feedback as well as technical feedback on the design. 
The reviews could have been based on formal sign-off lists or consensus reached through 
discussion. Because the design team was small(10 people) it was not necessary to incorporate 
formal sign-off authority within Goddard. Instead a consensus of the entire design team was 
reached on each issue. In order to keep track of input from reviews external to GSFC, a more 
formal review requiring sign-off authority has been implemented. 

The project plan deviated slightly from the typical procedure described above: 

1. Task Analysis 

2. Requirements Definition 

3. Conceptual Design 

4. Preliminary Design 

5. Detailed Design 

6. Fabrication 

7. Test and Evaluation(Verification) 

2.3 Task Analysis 

The next step in the project plan is to analyze the tasks to be performed. These tasks are 
derived from project goals and objectives. The task analysis uses a standard breakdown and 
terminology to categorize the actions performed by the system. The task analysis must be 
understood before any attempt is made to determine the operator interface. 
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Before the workstation testbed project began, it was assumed that an overall task analysis of 
FT S functions had already been completed. In fact, a task analysis had not been completed for 
FTS. Thus, it was necessary for the team to analyze the proposed FTS tasks and currently defined 
laboratory robot tasks. This process involved the analysis of FTS, NSTS, SSF, NASREM and 
robotics laboratory documents. Even though experienced personnel were compiling the task 
analysis, completing this task analysis increased the requirements definition phase of the project 
considerably. An example of the format used for the present task analysis effort is shown in Table 
1 . 

2.4 Requirements Definition 

Once the task analysis is complete, the requirements for the system are assembled. For an 
operator centered system, these requirements address the needs of the operator in performing the 
tasks as well as system requirements. One approach to finding the operator's needs is interviewing 
operators of similar systems and incorporating their feedback. 

The primary sources for the requirements definition of the workstation testbed were: 

1. The System/Function/Task Analysis of FTS functions(see above) 

2. The Phase C/D Source Requirements for the procurement of the FTS system 

3. The constraints imposed by the NSTS 

4. Interviews and documentation pertaining to the operations and plans of the Robotics Laboratory. 

Robotics laboratory robot operators at GSFC were also interviewed to gain insight into operators' 
requirements. The interviews with Robotics Laboratory personnel proved to be a valuable part of 
the requirements definition process. Since many of the interviewees were users of laboratory 
robots, their ideas had a significant impact on driving the requirements toward operator centered 
design. The final Top-Level Requirements document identified over 100 mock-up workstation 
testbed requirements. An example of the format used for presenting these requirements is shown 
in Table 2. 

2.5 Conceptual Design 

The operator interface should be addressed in a conceptual design document. This document 
includes the physical layout of the operator displays and controls that are used to accomplish a 
task. The display and control capabilities are described, as well as the functionality of the operator 
interface components. The conceptual design prompts early feedback from the operator concerning 
the layout of the displays and controls. This is important because the physical layout of the 
interface affects design issues. By reviewing the operator interface first, a human centered design 
approach is achieved. The Conceptual Design document describes: 1) the basic operator interface 
design philosophy, 2) the overall system configuration, 3) the approach proposed for displays 
and controls, 4) the principles suggested to integrate the displays and controls and 5) the necessary 
internal and external interfaces. It is generally easier to obtain feedback when a concrete design can 
be referenced. 

This Conceptual Design document was the mechanism used to obtain early feedback from robot 
operators, human-factors researchers, astronaut crew representatives and other groups involved in 
workstation design. In fact, the feedback received from the Conceptual Design document was 
instrumental in forming a more flexible design approach for the AFD workstation testbed. A 
sample of two possible workstation layout proposals can be found in Figure 1. 
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TABLE 1 


CONDENSED SYSTEM/FUNCTION/TASK ANALYSIS 
OF FTS LABORATORY SIMULATIONS 



NASREM 

LEVEL 


NASREM DESCRIPTOR 

SYSTEM/FUNCTION/TASK 

DESCRIPTOR 

I. ' 



(Purpose) 

8.0 

Goals: 





8.1 

Multi-purpose robot 
system 

II. 



( Implementation) 

7.0 

Flights Manifest 





7.1 

A DTF-1 

III. 

Level 

6 

Mission 

6.0 

Functions : 





6.3 

Service (Maintain) 

IV. 

Level 

5 

Planning/ 

5.0 

Scenarios: 




Scheduling 

5.7 

Replace a module 

V. 

Level 

4 

Ob j ect/Task 

4.0 

Tasks: 





4.5 

Sub-ORU changeout 

VI. 

Level 

3 

E-Move 

3.0 

Subtasks 





3.26 

Seat 

VII. 

Level 

2 

Primitive 

2.0 

Actions 





2.1 

Teleoperate 

VIII. 

Level 

1 

Servo 

1.0 

Elements 





1.2 

Joint positions 
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TABLE 2 

FORMAT FOR AFD WORKSTATION 
REQUIREMENTS DEFINITION 


1 . 0 Workspace Requirements 

1.1 Location and Enclosure 

1.2 Consoles 

1.3 Anthropometry and Ergonomics 

1 . 4 Environment 

2 . 0 Display Requirements 

2 . 1 General Display Information 

2.2 Visual Television Displays (CCTV) 

2.3 Visual ^Computer Displays (Monitors) 

2.4 Auditory Displays 

2.5 Tactile Displays 

3 . 0 Control Requirements 

3.1 General Control Capabilities 

3 . 2 Hand Controllers 

3 . 3 Camera Controls 

3 . 4 Lighting Controls 

3.5 Modes of Control 

4.0 Display/Control Integration (Architecture) Requirements 

5 . 0 Communications Requirements 

5.1 Operator Communications 

5.2 Equipment Communications 

6.0 Labelling Requirements 

7.0 Restraint System Requirements 

8.0 Safety Requirements 

9 . 0 Maintenance Requirements 

10.0 Electrical Requirements 

11.0 Thermal Requirements 
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DAP 


Combined Version 1 





FTS Video 
Screen 

General purpose 
THC/RHC 
hand controller 



FTS mini master 

RMS THC/RHC 
hand controller 


»>> RMS displays/ 
vXj controls 

FTS graphics 
screen 



FTS hook*on keyboard 


FTS displays/ 
controls 


FTS keyboard 


FTS displays/ 
controls 




2.6 Prototyping 

Conceptual design also involves constructing a mock-up of the operator interface. This is a 
full-scale non-operational form-and-fit mock-up with all applicable console spaces represented in 
approximately correct sizes and locations. The mock-up is useful in evaluating different 
configurations and high-level operator interface issues(such as display location) by testing 
participants using a physical model. This mock-up is modifiable to incorporate necessary design 
changes. 

The AFD workstation testbed prototype has the capability to evaluate different numbers of 
operators sharing different functions at different workstation panels. Workstation project 
personnel, senior engineers, managers and novice research participants are tested to obtain 
preliminary data on ease of operator functioning. 

2.7 Preliminary Design 

The Preliminary Design for the workstation testbed is a complete design at the system and 
subsystem level. Preliminary console layout drawings showing approximate dimension of 
equipment are prepared and feedback concerning technological and operational feasibility is 
encouraged. Operator feedback at this stage of design is used to critique the preliminary operator 
execution sequences. These sequences or scripts are "walked through" by users of similar 
systems, and checks are made for conflicts concerning operation. The preliminary system 
configuration must satisfy the equipment, personnel, software and procedure specifications laid out 
or implied in the Top-Level Requirements document. Also, the system design must incorporate the 
feedback from the Conceptual Design document. 

2.8 Detailed Design 

The next stage in the project plan is the detailed design. The detailed design deals with the 
specific equipment rather than systems and subsystems. One of the most important human factors 
functions that is performed in this phase is the checking of display and control devices. Once 
displays, controls and configuration have been specified, detailed layouts are evaluated for 
compliance with human factors criteria(i.e. NASA- STD-3000, Man-Systems Integration 
Standards, etc.). At this stage, the important characteristics to evaluate include size, color, number 
of controls and displays, and control-display arrangement. These evaluations are performed on 
detailed drawings of the operator interface. 

From these evaluation, a list of preliminary Human Engineering Deficiencies(HED) is 
generated. The HED's document die instances where human engineering design deficiencies exist. 
They also document the possible implications of each deficiency in terms of operator error, delay 
or dissatisfaction. Through operational and technical reviews, a decision is made to correct, ignore 
or compensate for the deficiency. 

2.9 Design Verification 

The next stage of the development process is operational testing and evaluation. From the 
human factors perspective, these tests determine if the assembled system meets human engineering 
criteria and is compatible with overall system requirements. Such testing and evaluation provide 
initial quantitative measurements of operator as well as system performance. 

The Test and Evaluation portion of the project plan is composed of two types of activities: 

1. Final checking of Human Engineering Deficiencies (HED) 
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2.10 Tests and demonstrations of operator/machine performance. 

The final checking is made on operating components. Checking the workstation to determine 
final conformity is far more thorough and precise. All HED's and their predicted consequences are 
documented. A decision is made to correct the deficiency or to leave it and note any implications 
for training and operations. 

An AFD workstation test plan is prepared in which test objectives will be identified and the 
proposed test methods will be described. Different populations are sampled to study various 
aspects of the user interface. The results of these experiments, tests and demonstrations are 
described in an operational test report. This report covers the test background, objectives, 
methods, controls, participants, prior training, apparatus, data collection, data reduction, data 
analysis and conclusions. The operational test report addresses quantitative results concerning 
how well operators performed the tasks as well as qualitative feedback from the operators about the 
workstation(i.e. ease of operation). This is the final stage were human factors feedback can be 
incorporated. 


2.11 Documentation and Training 

The final phase of the project plan insures effective workstation performance after final testing 
and acceptance. Procedures are developed to use the workstation. Proper operator's manuals are 
provided, and training implications are identified for task scenario evaluation. The task analysis, 
supplemented by test and evaluation results, serves as the basis for procedure development and 
training definition. Human engineering principles are applied to insure that the human functions 
and tasks are organized and sequenced for efficiency, safety and reliability of operation. Adequate 
operational, training and technical publications exist to properly support the workstation. 

3.0 Summary of Results 

The experiences of developing and applying this project plan have revealed important results. 
Some of these results are stated as general principles to guide thoughts and activities toward 
producing a more user-oriented design. Others are expressed as concrete steps and self-checks that 
can be applied to insure that the design effort stays oriented toward the user. 

3. 1 General Principles 

The following is a list of some of the general principles that were the result of this experience: 

1. Basic human factors guidelines should first be compiled 

The research literature and application examples on basic human factors is extensive. The 
workstation testbed project needed a broad set of guidelines or principles compiled from the 
literature to serve as a practical base for the design. 

2. Human factors should as much as possible drive the design process 

User issues were addressed as much as possible early in the system design process. A set of 
requirements was derived based on human factors design principles as applied to the NASA 
robotics environment. These requirements then formed the basis for later design activities. 

3. The user should be involved throughout the development process 

Conducting interviews with potential users was very helpful, especially for setting the proper 
direction early in the project. It was also important to include the actual and potential users in the 
review processes. 
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4. The operator interface should be designed for flexibility 

The workstation testbed would be reconfigured as basic ideas and basic system capabilities 
were added. Therefore, it became important to design in this flexibility and to build a modular, 
reconfigurable system. 

3.2 Concrete Steps 

1. Acquire a formal task analysis before beginning 

2. Organize a team that has at least one human factors expert 

3. Hold reviews that include users 

4. Develop a conceptual design of the operator interface early in the design process 

5. Build a physical prototype to resolve operator interface issues 

6. Evaluate operator interface and performance soon after final integration. 

4.0 Conclusion 

The purpose of this paper is to describe how to successfully direct a system design effort that is 
focused on the human operator. A project plan designed to insure the proper integration of human 
factors into the design process is described. The project plan makes use of operator feedback as 
the mechanism for human factors integration. The user feedback received thus far in the 
development of the workstation testbed indicates that this feedback is helping to create a good 
design. The final test will come when an astronaut uses the AFD mock-up workstation to operate 
the FTS robot emulator. 
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